Cratis.Screenplay 1.7.0 added an optional 'Types' parameter to the
ApplicationSyntax primary constructor. Source compatible, binary breaking:
the published Cratis.Arc.Screenplay is compiled against 1.5.2, so its call
site names a constructor that no longer exists and every generation ends in

  Method not found: 'Void Cratis.Screenplay.Syntax.ApplicationSyntax..ctor(...)'

Verified against both 1.7.0 and 1.8.0. The compiler used by 'screenplay
validate' therefore stays a release behind the one the Stage image runs
until a Cratis.Arc.Screenplay built against 1.7.0 or later is published.

The generator can name the module of each feature after the outermost
segment of its namespace, and reaches that only when nothing named a module
and no single assembly names the application - so an application whose
namespaces already say what its modules are comes back as one module holding
every feature, with no way to ask for anything else.

--modules-from-namespace-roots asks for it. Where every slice shares a root
namespace, that outermost segment is the root, so it pairs with
--skip-segments to move the modules down to the segment that tells them
apart: Samples/Library then emits Authors, Inventory and Lending as modules
rather than as features of one module Library.

Three ways a document came to describe something other than the application
it names:

A workspace opens a multi-targeted project once per target framework and
tells the results apart by appending the framework to the name, so a project
arrived as Lib(net10.0) and Lib(netstandard2.0). The spec-name test was asked
of that decorated name and no longer recognized MyApp.Specs, and the dedupe
grouped by it and so could never group anything - both compilations of every
multi-targeted project were handed to the generator. Both questions are now
asked of the name with the framework removed, and one target framework is
picked deterministically.

Whether a project holds part of the application is now asked of what it can
see: every artifact is declared with an attribute the framework ships, so a
project resolving neither the Arc nor the Chronicle one is left out. A Roslyn
analyzer or a build-time tool beside the application no longer says something
about the solution that is not true. Pointing at a single project still reads
it whatever it can see.

The host integration specs start the application in is turned away with the
specs it serves, by name, because it references the same framework the
application does and nothing it can see tells it apart.

A solution filter is accepted and read as the solution it filters.

An unrestored project still opens and still yields a compilation - one with
no package reference resolved, in which every framework type the application
uses reads as missing. Generating against an unrestored solution therefore
produced eleven SP0024 errors saying 'Chronicle' does not exist in the
namespace 'Cratis', a 494-line document describing nobody's application, and
not one word about running a restore.

The assets file is asked for before anything is compiled, and its absence is
reported as CLI0005 naming the projects and the command to run. Nothing is
generated, because a document read from a half-resolved compilation can only
mislead. Where the intermediate output folder was moved - the artifacts
output layout of the SDK moves it out of the project folder - it is found
through the assembly the project compiles into it, and a project neither path
says anything about is taken for restored rather than failed.